home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 5435 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.3 KB  |  51 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: chang.unx.sas.com!walker
  3. From: walker@chang.unx.sas.com (Doug Walker)
  4. Subject: Re: Ceck out this bug. What the *** is SASC/6.56 doing?
  5. Sender: news@unx.sas.com (Noter of Newsworthy Events)
  6. Message-ID: <Do9Gpy.Juv@unx.sas.com>
  7. Date: Thu, 14 Mar 1996 14:10:45 GMT
  8. X-Nntp-Posting-Host: chang.unx.sas.com
  9. References: <1120.6643T91T406@login.eunet.no> <v24trvir4v.fsf@athena-e.eurpd.csg.mot.com> <879.6646T4T2378@login.eunet.no>
  10. Organization: SAS Institute Inc.
  11.  
  12. In article <879.6646T4T2378@login.eunet.no>,
  13. Patrick Hanevold <patrick.hanevold@login.eunet.no> wrote:
  14. >
  15. >>You're probably overflowing your stack.  That ULONG Palette is 6144 bytes,
  16. >>and since it is a local variable it is stored on the stack.
  17. >Try dividing by two, then you are getting a little closer. :)
  18. >
  19. >>Look at your CLI stack size.  If it's low (especially lower than 7000)
  20. >>then you need more.  Set it to 20K and I bet you don't crash.
  21. >
  22. >>In SAS you can set long __stack = 10000 or whatever to force the program's
  23. >>stack to be larger.  Then you won't have to worry about the CLI stack.
  24. >
  25. >If it is the stack, then SC's stack check routines are crapp.
  26.  
  27. The SAS/C stack check routines are performing exactly as documented and
  28. exactly as designed.  They are doing everything it is reasonable to expect
  29. them to do, namely, make sure that the function compiled with stack checking
  30. has enough stack for its use.  If you think it is possible for the compiler
  31. to protect your program against every stupid thing it tries to do, you are
  32. sadly mistaken.  The responsibility to make sure your program behaves 
  33. intelligently is yours, not the compiler's.  I suggest you read the section
  34. of the manual devoted to disussion stack checking, stack extension, and
  35. the runtime architecture of a C program.
  36.  
  37. >Anyway, none of the OS calls themseves crash. Its SC's exit routines
  38. >that messes around in memory. Avent checked so much whats going on around
  39. >there, but it shouldnt crash with stack check or stack extend on.
  40.  
  41. With a stack trash, it is quite likely that nothing bad would happen 
  42. before the program exits.  It all depends on what is lying around in
  43. memory that happened to get trashed when the stack was overrun.
  44.  
  45. -- 
  46.   *****     
  47.  *|_o_o|\\     Doug Walker   walker@unx.sas.com  
  48.  *|. o.| ||                
  49.   | o  |//     Any opinions are mine, not those of SAS Institute, Inc.
  50.   ====== 
  51.